User Authentication

The OIPA application provides an out-of-the-box user authentication mechanism as well as an ability to implement alternative authentication models like Single Sign-On (SSO) authentication through the OIPA extensions. If the system is implemented with SSO, additional measures need to be taken to properly secure the authentication infrastructure. Depending on the implementation chosen, either an authentication server should be placed within the OIPA application server and database zone, or the call to an authentication service needs to be made via a secure connection.

Out-of-the-box OIPA user authentication is performed for interactive users using web browsers to access the system, and for incoming web service calls. Interactive users are prompted on the application's login page to provide a username and password to authenticate to the server. Web services are protected with WS-Security, which requires incoming web service calls to be transmitted on a secure SSL connection and carry a security header with a user name and password.

Both web service and interactive user authentication are implemented through the same authentication service provided by the business logic tier of the OIPA application. The authentication service retrieves a matching user record from the OIPA database that contains basic user information and a secure digest of a password. The password digest is then compared to the digest of the incoming password and an authentication decision is made based on the result of the comparison. For certain web services, apart from user authentication, additional functional security is also enforced to control whether those services can be executed.

Native SSO Authentication

OIPA also supports Native SSO using OpenID Connect (OIDC). Native SSO is enabled through the runtime property application.isSSOEnabled=true. When enabled, the application loads oidc-config.yaml from the runtime classpath and uses the configured OIDC issuer discovery endpoint to obtain the provider metadata required for authentication.

For OIPA browser-based login, Native SSO uses the OIDC Authorization Code flow. During login initialization, OIPA returns an authorization URL instead of the standard login model. After successful authentication with the identity provider, the authorization code is exchanged for tokens, and the access token is validated using the provider JWKS endpoint. User claims from the validated token are then mapped to OIPA user attributes such as client number, first name, last name, and email.

If the authenticated user does not already exist in OIPA, the application can create the user locally and assign the configured default security group and primary company values. Refresh tokens are stored for logout and session extension processing. Logout uses the provider end-session endpoint when available.

When Native SSO is enabled, all OIDC endpoints, redirect URIs, and application entry points must be secured over HTTPS. The configured issuer, audience, redirect URI, and claim mappings must match the identity provider configuration. The OIPA environment must also contain the configured default company and security group values required for local user provisioning.

For PASService and CycleService, Native SSO support is also available through the same OIDC configuration model. Refer to the Native SSO User Guide (12.2.0.0 OIPA Native SSO User Guide) for service-specific behavior, required identity provider settings, and claim or role mapping requirements.

OIPA User Authentication

OIPA_UserAuthentication

The encrypted password digest is created by the Rules Palette when a user is created. When a new OIPA environment is created using the Rules Palette's Web Application Utility, the process allows for the configuration of the encryption parameters to be used by the encryption algorithm. The settings include the particular encryption algorithm (from the list of the supported algorithms below), and the number of iterations of the algorithm.

  • SHA-256

  • SHA-384

  • SHA-512

The number of encryption iterations is a value between 1000 and 9999. A higher number of iterations makes the password more secure, but also requires more computation to encrypt. For more information, refer to the associated version of the Rules Palette Help System that is available in the Policy Administration Libraries of Oracle Help Center.